你了解反向 ETL吗？
反向 ETL 促进了运营分析，避免了数据孤岛，并使运营团队能够在不离开他们信任的工具的情况下做出明智的决策。
反向 ETL 已成为现代数据栈中的标准模式。如今组织和从业者利用 Census 和 Hightouch 等反向 ETL 工具将分析同步回运营系统。这有助于将分析带回到最重要的地方：运营决策。反向 ETL 促进了运营分析，允许运营团队在不离开他们熟悉的工具集情况下做出明智的决策。本文深入探讨了反向 ETL，以了解它为何如此重要、它是如何工作的以及它为业务带来的价值。
运营团队和数据团队
起初没有数据仓库。组织有不同的运营团队；销售、营销、产品和客户支持团队利用运营系统来完成他们的日常业务任务。CRM、支持帮助台、HR 系统和 JIRA 都是员工和客户接触到的例子。当组织随着时间的推移而增长时，领导者想要衡量业务的表现，这就出现了商业智能 (BI) 工具，要求使用运营数据生成报告和 KPI 仪表板，例如生成上周的销售报告，要求 BI 工具从 Salesforce 等 CRM 中提取销售数据，数据团队拥有 BI 和其他分析流程，将职责与运营团队分开。
ETL的诞生
**针对运营系统运行 BI 是不可扩展的，因为它会对性能造成严重影响。**因此人们将数据从运营系统转移到数据仓库等中心位置，从而允许使用不同的 BI 工具并运行大规模分析。该过程需要从运营系统 (E) 中提取原始数据，对其进行清理和转换 (T)，然后将它们加载到数据仓库 (L) 中。这为 1970 年代开始的 ETL 实践铺平了道路。
数据仓库解决问题了吗？
今天在企业数据管理方面，组织比 60 年代和 70 年代要好得多。由数据科学家、分析师和工程师组成的数据团队利用现代数据工具做出明智的决策，数据平台的重心已经转移到像 Snowflake、Google BigQuery、Amazon Redshift、Azure Synapse 等数据仓库。但是所有这些现代数据仓库是否有让让运营团队更轻松？这些现代数据工具如何促进高效、轻松的运营分析？似乎分析尚未充分发挥其能力。
数据激活时的摩擦
让我们举一个现实的例子来更好地理解。考虑销售合格潜在客户的客户评分示例。通常销售线索从 Salesforce 等 CRM 工具同步到数据仓库，应销售团队的要求，数据分析师生成并共享包含潜在客户分数的报告。该报告托管在一个 BI 工具中，要求销售人员在访问它之前登录，由于公司安全政策，这使得它变得困难。需要导航到 BI 工具、提供用户凭据、回答 OTP 等。
最终这种摩擦常常导致报表没有人打开，在 BI 工具中闲置，浪费数据分析师的时间和精力，此外这并没有闭环反馈循环分析——分析师永远不会收到关于他工作的反馈。
打破数据孤岛以进行运营分析
这就是我们今天所面临的严酷现实。现代分析基础架构提供更高级的分析，但它未能走完数据旅程的最后一英里；数据激活。位于仓库或 BI 工具中的分析创建数据孤岛。这需要对运营团队进行培训以使用 BI 工具，这通常是一项艰巨的工作，并且在现实中不能很好地扩展。如果运营人员不使用 BI 工具，我们需要将分析引入他们的行业工具。这称为运营分析[1]。
如果我们将潜在客户分数同步回 Salesforce，这是销售团队使用的最友好、最值得信赖的运营工具，会怎样？通过将潜在客户的加权分数显示为 Salesforce 中的一个字段，这将使销售人员的生活更轻松。
这样销售人员永远不会离开运营工具来访问运营分析，即每天做出明智决策所需的数据。反向 ETL 是一个很好的推动者。让我们来了解一下。
什么是反向 ETL？
反向 ETL 领域的领先供应商 Hightouch[2] 将反向 ETL 定义为：
反向 ETL 是将数据从中央数据仓库复制到记录运营系统的过程，包括但不限于用于增长、营销、销售和支持的 SaaS 工具。
反向 ETL 与 ETL 相反，将分析的数据从数据仓库同步回运营系统。反向 ETL 改进了数据激活，使运营团队能够在不离开运营工具的情况下做出数据驱动的决策。
它是如何工作的？
反向 ETL 不是另一种需要重新架构数据平台的架构范式。相反它非常适合现有的数据工具和实践。像往常一样，ETL/ELT 工具将运营数据同步到数据仓库，允许数据团队处理请求的运营分析。例如，分析师和数据科学家会产生如下分析：
• 购买倾向
• 个性化内容/产品推荐
• 流失客户账户的风险因素
• 营销活动的转化率和归因
• 客户终身价值 (CLV)
通常数据团队使用 dbt[3] 之类的工具将原始数据转换为高保真数据分析模型，并将它们同步回仓库。反向 ETL 工具将这些数据模型从仓库同步回诸如 CRM、支持帮助台、营销自动化等运营系统。例如，Salesforce、Zendesk、Marketo、Hubspot 等。
为什么我们需要反向 ETL？
随着越来越多的组织变得数据驱动，对反向 ETL 的需求增加，主要有两个原因。
• 整个组织中灌输运营分析文化：将分析卡在数据仓库或 BI 工具中会阻碍数据驱动的决策制定。运营团队通常不得不依靠数据团队将分析转化为他们的运营领域。反向 ETL 工具通过将运营分析带回运营系统打破了这一障碍，允许运营团队利用分析进行日常决策。
• 自动化数据基础架构：如果没有反向 ETL 工具，开发人员和数据工程师将不得不构建管道和 API，将分析同步回不同的运营系统。反向 ETL 工具消除了这种痛苦，并从单个控制平面自动同步。
结束语：反向 ETL——变相的企业集成？
作为一名经验丰富的企业集成架构师，我的思维过程总是回到将反向 ETL 视为集成中间件的一个奇特术语。过去我们使用 ESB 之类的中间件来避免企业应用程序和数据库之间的点对点集成。我认为反向 ETL 工具正在走同样的道路。在这两种实践中，我们都有一个源系统和许多不同的目标系统，以便以可靠和可扩展的方式移动数据。我认为在技术细节方面没有区别。用户可以使用 ESB 或反向 ETL 工具完成这项工作。但是在我看来，反向 ETL 工具是专门为与现代数据栈一起使用而构建的，通过预构建的连接器提供与运营系统的无缝集成。此外它们已经开始在许多数据平台中发挥关键作用，使反向 ETL 成为标准模式。
引用链接
[1] 运营分析: [https://blog.getcensus.com/what-is-operational-analytics/](https://blog.getcensus.com/what-is-operational-analytics/)[2] Hightouch: [https://hightouch.io/](https://hightouch.io/)[3] dbt: [http://getdbt.com/](http://getdbt.com/)